home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c / 53 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  1.5 KB
  1. Path: tools.bbnplanet.com!not-for-mail
  2. From: barmar@tools.bbnplanet.com (Barry Margolin)
  3. Newsgroups: comp.std.c
  4. Subject: Re: Undefined result vs. int's holding undefined values.
  5. Date: 8 Jan 1996 21:45:20 -0500
  6. Organization: BBN Planet Corp., Cambridge, MA
  7. Message-ID: <4csks0$44p@tools.bbnplanet.com>
  8. References: <4ck70b$rd7@news.informix.com> <4cmg0s$1mb@der.twinsun.com> <oZA8wQ9ytpjN084yn@csn.net> <4cs460$d6e@news.informix.com>
  9. NNTP-Posting-Host: tools.bbnplanet.com
  10.  
  11. In article <4cs460$d6e@news.informix.com>,
  12. Daniel Wood  <dwood@informix.com> wrote:
  13. >I totally understand what you are doing in the above but this would have to
  14. >be the ultimate in a cheap out for a vendor.  SCO could claim that before
  15. >ever looking at a test case containing a suspected compiler bug that every
  16. >arithmetic calculation would have to first have a test similar to the above
  17. >to protect against overflow/underflow.
  18.  
  19. I don't think that's a valid analogy.  The original code intentionally
  20. caused overflow, and depended on a particular behavior as a result.
  21.  
  22. A test case doesn't have to prevent overflows.  The submitter of the bug
  23. report merely has to show that his test values will never cause overflow.
  24. Most programs don't check for overflow because it's generally impractical
  25. and unlikely (applications that deal with such large quantities either use
  26. floating point of arbitrary-length arithmetic libraries).
  27. -- 
  28. Barry Margolin
  29. BBN PlaNET Corporation, Cambridge, MA
  30. barmar@bbnplanet.com
  31. Phone (617) 873-3126 - Fax (617) 873-6351
  32.